Azure Active Directory Domain Services ( Azure AD Domain Services ) を試してみた
しばたです。
ちょっとお仕事に関連してAzure Active Directory Domain Servicesを試す必要があったのでブログにまとめてみました。
Azure Active Directory Domain Services とは？
Azure Active Directory Domain Services (Azure AD Domain Servicesとも記される。本記事ではさらに略して以後AAD DSと表記)はその説明に
マネージド ドメイン サービスを Azure で使用する
Azure Active Directory Domain Services を使うと、ドメイン コントローラーをデプロイせずに、Azure 仮想マシンをドメインに参加させることができます。会社の Azure Active Directory 資格情報を使用してこれらの仮想マシンにサインインし、各種リソースにシームレスにアクセスできます。
とある様にAzure環境上にマネージドなActive Directoryドメイン環境を提供するサービスです。
その実装としてはMicrosoft管理の2台のWindows Server 2012 R2から構成されています。
Azure Active Directory Domain Services に対する大きな誤解
私は当初AAD DSをその実装からAWSにあるAWS Managed Microsoft ADと同様のManagedなADDSサービスだと認識していたのですが、実際に触れてみるとそれは大きな誤りであることに気が付かされました。
AAD DSは確かにManagedなADDSとして使うことは可能なのですが、単純に「ManagedなADDSサービスである」と言い切るわけにはいかない非常に大きな制約がいくつかあります。
まず最初に「AAD DSはAzure ADからのユーザー同期を強制される」点です。
設定により同期するグループを絞ることはできますが、同期そのものを無効にすることはできません。
AAD DSにおいてはユーザー管理はAzure AD上で行うのが基本であり、「Azure ADのユーザーをそのまま通常のAtive Direcotry環境 on Azureで使うためのサービス」というのが正しい見方だと思います。
AAD DSの基本構成とユーザー同期に関してはざっくり下図のイメージになります。
(AAD DSにはAzure ADのユーザーが同期され、ユーザーのUPNは同一のまま同期される。その他項目についてはこちらを参照)
次に「AAD DSは1 Azure ADテナントあたり1環境のみ作成可能」という制約があります。
この点はManagedなADDSサービスとして考えると非常に大きな制約ですが、Azure ADとのユーザー同期の観点からすると納得のいく仕様です。
加えて、AAD DSのSKUによっては既存のAcitve Directory環境と信頼関係を構築することができるのですが、「信頼関係の方向はAAD DS → 既存のAcitve Directory環境のみ」となります。
この仕様も「Azure ADのユーザーをそのまま通常のAtive Direcotry環境で使うためのサービス」という観点で見ると納得がいくかと思います。
AAD DSがなんのためのサービスであるかという点についてはAzure AD サポートチームのブログにも、
Azure AD Domain Services は、基本的に Azure 上に構築したサーバーやクラウド上のサービスに、Azure AD のアカウントを利用したドメイン参加や Kerberos 認証、LDAP アクセスを直接許可することを目的として提供されています。
ときっちり記載されています。
こちらのブログはAAD DSを使うべきユースケース、逆に使うべきでないユースケースについて丁寧に説明されてますので一読することをお勧めします。
私個人としてはこのサービスはAzure AD Domain Serivcesというよりは「Azure AD ADDS Endpoint または Azure AD Kerberos Endpoint」とでも呼称するほうが実態に近い気がしています。
(ADDSであることよりAzure ADのいち役割に過ぎない点を強調したい...)
やってみた
ながい前置きはここまでにして、ここから実際に試していきます。
検証環境
今回つくる環境は下図になります。
検証用Azure環境に172.16.0.0/16のVNetと172.16.1.0/24、172.16.2.0/24の2つのサブネットを用意し、172.16.1.0/24のサブネットにAAD DS環境を構築していきます。
ちなみに、AAD DSが配備されるサブネットには独自のネットワークセキュリティグループが適用されるため、専用の新しいサブネットを用意する様にしてください。
動作確認用にもう一つのサブネットに適当なWindows Server 2019仮想マシンを用意します。
(この仮想マシンの構築手順については割愛します)
1. リソースグループ、VNet、サブネットの作成
まずは前準備としてリソースグループ、VNet、サブネットを作成しておきます。
ざっくり以下の内容のリソースを作成します。
| リソース | 名称 | 設定値 | 備考 |
|---|---|---|---|
| リソースグループ | AADDS-Test | ||
| VNet | aadds-test-vnet | 172.16.0.0/16 | リージョンは東日本 |
| サブネット | aadds-subnet-1 | 172.16.1.0/24 | |
| サブネット | aadds-subnet-2 | 172.16.2.0/24 |
今回はポータルから以下の様な感じで作成しています。
(ここは本筋ではないのでスクリーンショットの列挙だけにとどめておきます)
2. Azure Active Directory Domain Services の作成
ここからAAD DSを作成していきます。
ポータルから「domain」で検索するとAAD DSをすぐ見つけることができます。
AAD DSのサービス画面に遷移したら「追加」か「Azure AD Domain Services」の作成ボタンをクリック。
作成ウィザードが開始されるので「基本」欄は以下の様に設定。
| 項目 | 設定値 | 備考 |
|---|---|---|
| リソースグループ | AADDS-Test | |
| DNSドメイン名 | azure.shibata.tech | ここがActive DirectoryのDNS名になる |
| 地域 | 東日本 | VNetと同一リージョン |
| SKU | Standard | 今回はStandardを選択 |
| フォレストの種類 | ユーザー |
SKUごとで提供される機能については価格ページがわかりやすいです。
(上図は2020年7月29日時点の価格)
「ネットワーク」欄は以下の様に設定。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 仮想ネットワーク | aadds-test-vnet | |
| サブネット | aadds-subnet-1 |
「管理」欄はデフォルト設定のまま次へ。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 通知 | Azure ADの全体管理者、AAD DC Administrators | デフォルト設定 |
「同期」欄もデフォルト設定のまま次へ。
| 項目 | 設定値 | 備考 |
|---|---|---|
| 同期の種類 | すべて | デフォルト設定。Azure ADの全ユーザーを同期 |
最後に確認画面になるので、設定値に誤りがないことを確認して「作成」ボタンをクリック。
最終確認ダイアログが表示されるので「OK」をクリック。
するとデプロイが開始されるので完了するまで待ちます。
デプロイが完了するとAAD DSリソースに移動できますが、ドメイン環境のプロビジョニング作業がもうしばらくかかります。
プロビジョニングが完了しAAD DSの状態が「実行中」になれば完了です。
プロパティを確認するとこんな感じになります。
3. AAD DC Administratorsグループの設定
AAD DS環境を作成するとAzure ADに「AAD DC Administratorsグループ」が作成されます。
このグループがAAD DSの管理者となるのですが、初期状態では誰もこのグループに所属していません。
このため最初に適当なAzure ADユーザーをメンバーにしておく必要があります。
今回は新規に[email protected]ユーザーを作り管理者にしました。
(tarou.yamadaの詳細はこんな感じ。新規にユーザーを作った場合は初回ログイン時にパスワード変更要求がありますのでログインを済ませパスワードを変更しておいてください。でないとAAD DSにパスワードが同期されません)
以上で最低限必要な初期設定は完了です。
4. AAD DSへの接続
AAD DSが提供するActive Direcotryへの接続にはAAD DC Administratorsグループのユーザーを使用します。
PowerShellからだとざっくり以下の様な手順になります。
#
# 要管理者権限
# 事前にDNSサーバーを設定をAAD DSのIPにしておくこと
#
# 通常のドメイン参加と同様に Add-Computer を使うが認証に使うユーザーは Azure AD のUPN (@xxxxxxx.onmicrosoft.com)で指定する
$cred = Get-Credential '[email protected]'
Add-Computer -DomainName 'azure.shibata.tech' -Credential $cred
- 参考 : VM をマネージド ドメインに参加させる
仮想マシンを再起動すれば無事AAD DSに参加できます。
AAD DS環境を調べてみた
これまでの内容を踏まえて動作確認用仮想マシンをAAD DSに接続、各種管理ツールからActive Directoryの情報を調べてみました。
Active Directory ユーザーとコンピューター
Active Directory ユーザーとコンピューターを見てみるとこんな感じです。
AADDC、AADDSで始まるシステム管理のOUがいくつかあることがわかります。
Azure ADのユーザーはAADDC Usersに同期されています。
同期されたユーザは下図の様な感じでAzure ADと同じUPNを持っています。
ちなみに、独自のOUを作成しOU内に独自のユーザーを追加することは可能です。
グループポリシー
グループポリシー管理はこんな感じ。
Azure ADから同期されたユーザー向けポリシー(AADDC Users GPO)、ドメインに参加したコンピューター向けのポリシー(AADDC Computers GPO)がデフォルトで用意されていますね。
AAD DSではグループポリシーは普通に使えますが、Default Domain PolicyやDefault Domain Controllers Policyは編集不可なのでご注意ください。
Active Dicrectoryドメインと信頼関係
Active Dicrectoryドメインと信頼関係はこんな感じ。
機能レベルは「Windows Server 2012 R2」となってます。
当然ですが信頼関係はデフォルトでは無いですし手動で作成する権限もありません。
また、代替UPNサフィックスも変更する権限はありませんでした。
グループ管理サービスアカウント(gMSA)
gMSAはAAD DSでも使用することができ、その仕様についてはAWS Managed Microsoft ADと同様で
- KDSルートキーは非表示だが初期状態で作成済み
- gMSAを作成する際はいきなりNew-ADServiceAccountコマンドレットを実行してOK
となっていました。
参考資料
この記事を書くにあたりいくつかのサイトの内容を参考にしました。
この記事で触れている点以外にオンプレActive Direcotryとのハイブリッド構成についても触れられており非常に参考になります。
- Active Directory 構築不要！！ Azure AD Domain Services とは？
- Azure AD Domain Services の構築
- Active DirectoryのPaaS版、Azure Active Directory Domain Servicesとは？
最後に
以上となります。
最初に述べた様にAAD DSというものを思いっきり誤解しており実際に触って試してみることの大事さを思い知らされました。
本記事の内容がこれからAAD DSを試してみる方の参考になれば幸いです。
